Groupmanager Plugin

Groupmanager is a tool intended for independent working groups within a single DokuWiki-installation. Group-admins can easily administer the users of their group and assign them roles without interference of - or interfering with - a super-admin. A complete setup for creating a context for working groups is described below to help you start up.

Usage of this plugin is actually quite easy, don't be mistaken by the length of this document, this is only to aide you.

Groupmanager is based on the original plugin groupmgr by Alex Forencich. groupmgr has not been updated since 2010. For some reason it was marked devel-only, but the idea is great! And Alex is still running it on his site.

Groupmgr already allowed easy modification of group membership by non-admins. This greatly simplified management of collaborative projects by group-admins.

Groupmanager adds in functionality from the usermanager by Christopher Smith. This way existing users can easily be found and assigned to groups in Wikis with many users. Groupmanager may also enable group-admins to add or delete users from the Wiki independently from a super-admin within the bounds of the groups they administer.

Groupmanager has been designed with a certain scenario and setup in mind. This scenario is helpful to make Groupmanager a workable solution. That's why it is worked out below in more detail.

Please read the Groupmanager Scenario for Working Groups and look for yourself whether this applies to you.

• Maybe people can come up with different scenarios. I actually still have to read my first book on PHP So any suggestions and improvements of the code are more than welcome!
• In the rest of this text the word “groupmanager” will be written in bold case if it refers to the plugin to avoid confusion with a person that is a group-admin.
• At this date (2013-05-25) groupmanager is used in a closed Wiki on a hosted plan with 350 trusted users and 6 group-admins for half a year now without problems. The authentication backend is MySQL; the user-database is expected to grow to about 8000. (Actually by now it is running with 8500 users — Harald 2013/11/05 22:42)
• I have been running this up to Binky now, no problems seem to arise. Depending on the template, sidebars and number of roles the interface may run off the screen. Try using fewer roles and hide the sidebar for the managing page.
• It is certainly possible to create a security problem for yourself with this plugin. And certainly so if you do not use the config_namespace option properly. Use groupmanager at your own risk. Think twice about your setup and have a look at the Groupmanager Scenario for Working Groups!

Search and install the plugin using the Extension Manager. Refer to Plugins on how to install plugins manually.

~~groupmanager|[groups to manage]|[allowed users and groups]~~

Groups to manage separated by commas; the first group in the list will be the default group.

Be careful: Use ~~groupmanager~~ in lowercase letters; ~~GROUPMANAGER~~ may not work!

~~groupmanager|wg_mygroup_reader|@wg_mygroup_admin~~

Members of group ‘ wg_mygroup_reader ‘ can be managed by group ‘ wg_mygroup_admin ‘

~~groupmanager|wg_mygroup_reader, wg_mygroup_editor|harald, @admin~~

Members of ‘ wg_mygroup_reader ‘ and ‘ wg_mygroup_editor ‘ can be managed by user ‘harald’ and members of the group ‘admin’

1. In the examples above groups managed by groupmanager are named following the naming convention “wg_[groupname]_[role]”. This is not required by the syntax, but I would advise it nevertheless. (Side note: The interface beautifies the name of groups for simple users a bit by deleting the prefix “wg_”, replacing “_” with “ ” and capitalizing the first letter of the resulting words.)
2. super-admin groups can only be managed by super-admins
3. Group-admins may assign the group-admin role to other users!
4. But: users cannot remove themselves from the group that grants them access to the group admin (including admins)
5. The conf_namespace option specifies a separate namespace for configuration. When the config namespace is used, a placeholder tag (~~groupmanager~~) can be used in the actual page while the full tag is placed in the configuration namespace at config_namespace:ID.
   If require_conf_namespace is set, all configuration options placed in the page are ignored, necessitating the use of the configuration namespace. For security reasons, this is the default configuration.
6. The “forbidden_groups” configuration setting specifies groups that cannot be edited with the plugin (only relevant if conf_namespace is not configured).
7. If allow_add_user is set, a dialog will be present in the interface that will allow users to be added to the Wiki. They will be automatically added to the “default” group, which is the first managed group (wg_mygroup_reader in the example).
8. If allow_delete_user is set, checkboxes will be added to each user-record. Clicking on “update group” will delete checked users.

This scenario addresses a situation with a single super-admin, a considerable number of users and independent working groups of an organization. Group membership is dynamic and always having to ask the super-admin is a nuisance. Making more people a super-admin is no option. Either because most people lack the knowledge or because the responsibility for the Wiki as a whole should stay centralized.

Wikis are all about “everybody may edit”, closed Wikis are in a way a contradiction in terms; Groupmanager regains some of the freedom that is lost in a closed Wiki. A working group may administer its members itself through an easy interface that is comprehensible for simple users. (Even while being the super-admin myself in most cases I am in fact quite happy with this interface. ☺)

Actually to be able to describe this scenario I need to make a little semantic switch to avoid confusion.

A “working group” in my definition will feature a set of roles that should contain a member- and a group-admin-role at minimum. So what is normally referred to as a “group” within DokuWiki-terms, I will call a role within the context of a working group.

Every working group has its own private namespace and a set of roles, which the group-admin may assign to Wiki-users.

A typical set of roles would be:

• Reader as default,
• Editor and
• Group-Admin

This scenario relies on the use of a groupmanager-configuration namespace only accessible for super-admins. This way the use of groupmanager-syntax is bound to specific pages and settings will always be taken from a protected page as defined by a super-admin.

With some copy-pasting the complete setup of a working group should take about 10 minutes.

To actually create a working group a super-admin needs to:

• create a configuration-page specifying the three roles for the working group in the groupmanager-configuration namespace
• create the namespace of the working group
• create a groupmanager administration page within the namespace of the working group, that only the working_group-admin may access. (The administration-page will take its setting from the protected configuration page.)
• define the three roles with the appropriate rights in the ACL and
• assign the group-admin role to at least one user.

From that moment on the group is basically independent; no further interference of the super-admin is necessary. The group-admin can build and administer his group on his own.

On the administration page of his working group a group-admin can view and search the complete user-list of the Wiki and add users to the working group by assigning roles to them. He can also quickly filter the user-list for existing working-group members.

If configured that way he may also create Wiki-users by his own accord. Users created by a group-admin will automatically be assigned to the default-role of the working group (working_group_reader in our case) and will thus be restricted by that role.

A group-admin may (optionally) delete users, if and only if they do not belong to any other DokuWiki-group outside of the roles of his working group.

In this example working groups are given a separate root-namespace at :working_groups. This way they can share ACL-settings and it is easily possible to have a “public” part in the Wiki in parallel that is visible to the world. (For any namespace I will always create a start-page describing the contents or use of the namespace. Next to good practice this comes in handy when using a plugin like Indexmenu. Indexmenu is a great support for automatic page discovery and providing ACL configured menus. I patched Indexmenu to support my setup.)

If you have not yet done so:

• install groupmanager through the plugin manager
• go to the admin configuration panel
• check mark option “Require configuration namespace”
• set option “Configuration namespace prefix” to :working_groups:wg_admin:groupmanager:

• create a starting page for all your working groups at :working_groups:start
• set access to the working group root namespace :working_groups to NONE for ALL if your ACL does not do this by implication already. (Depending on your setup you could consider allowing read-access to the starting page for ALL)
• create the page :working_groups:wg_admin:groupmanager:start. This will create the path for the “Configuration namespace prefix” (you could use this start page to keep all your notes about your Groupmanager installation).
• allow access to the namespace :working_groups:wg_admin to super-admins only; in this space you could put all super-admin-only pages.

Let the name of the working group be “wg_mygroup” in this example.

Create the configuration file for the workgroup at

working_groups:wg_admin:groupmanager:working_groups:wg_mygroup:admin:start

Put the code below into to the new page and save it. You might optionally add some helpful text for your group-admin to this page.

===== - Configure [working_group_name] Group - =====

~~groupmanager|wg_mygroup_reader, wg_mygroup_editor, wg_mygroup_admin|@wg_mygroup_admin, @admin~~

This will create three roles in the groupmanager interface

• wg_mygroup_reader (Readers)
• wg_mygroup_editor (Editors)
• wg_mygroup_admin (Group-Admins)

For any working space three roles are defined. Readers, Editors and Managers. Higher roles include all the rights of the lower roles in this case. By default ALL have no access at all to the working group space (in a closed wiki this setting is probably inherited and may not have to be set explicitly).

• Readers can view all content in the namespace of the working group
• Editors have basically edit/upload rights on the whole space of the working group
  Exception: they have no rights for the public and the admin namespace
• Group-Admins have read rights on the admin namespace (read is enough to use the administrator page)

These rules can be assigned through the interface or by editing /config/acl.auth.php

Click on the Admin-button choose “Access Control List Management” and set the appropriate rights (see below).

You need SFTP-access to edit /config/acl.auth.php. Copy the code below and append it to /config/acl.auth.php in your installation.

working_groups:wg_mygroup:*	@wg%5fmygroup%5freader	1
working_groups:wg_mygroup:*	@wg%5fmygroup%5feditor	8
working_groups:wg_mygroup:*	@wg%5fmygroup%5fadmin	16
working_groups:wg_mygroup:admin:*	@wg%5fmygroup%5freader	0
working_groups:wg_mygroup:admin:*	@wg%5fmygroup%5feditor	0
working_groups:wg_mygroup:admin:*	@wg%5fmygroup%5fadmin	1

%5f is an HTML underscore. I don’t know whether this is really required but that’s how I found it in the ACL.

This way the ACL (Access Control List) will be in place before the actual pages are available, so there is no intermediate security hole.

Create the starting page for the working group at :working_groups:wg_mygroup:start

Put in some text describing the group etc. and some advice to start them up. I use some standard text for that.

• Create :working_groups:wg_mygroup:admin:start
• Copy the code below into the new page and add some help text for your group-admin if you have not done so already in the configuration page.

===== - Manage Group - =====

~~groupmanager~~

Only group managers will have (read) access to this page. The additions to the ACL should have made sure of that. Managers can use the functionality of the plugin-page, but must not have edit-rights on the page itself to prevent illiterate group-admins from accidentally (WYSIWIG -editors etc.) deleting syntax lines.

• The example set of roles presented is just that, all kinds of other (complex) roles are conceivable, possibly reaching out of the working group’s closed namespace. For example the role of a “publisher” appeals to me. Publishers could get the sole edit-rights to a namespace accessible for the outside world. This could be the space where the working group presents itself and its results and can be indexed by Google.
• More than three roles for a working group are likely not efficient and the UI of the administrator page may become cluttered too. Four roles are really the maximum in my opinion.
• Filtering the user-list for group members on an administration page is currently a bit dependent on a naming convention. The filter searches for users that are member of the default group. So either you have to assign the default-role always to all members (preferred) or you choose for example the name of the working group as default and add the other roles to the name of the working group (example: wg_working_group, wg_working_group_reader, wg_working_group_admin).

• Add “allow add user” and “allow delete user” as options to the syntax, so these options can be configured for each working group separately. Currently allowing group-admins to add and delete users are global options in the main config of the Wiki.
• A support-plugin for groupmanager, that runs a script creating the setup for a basic working group taking its arguments from a form (somebody?).
• Let users request to join a group, and let group admins accept/reject join requests.

If somebody is using groupmanager please tell me your experiences. — Harald 2014/04/18 15:51

1. This plugin is great, especially for people switching from PMwiki to DokuWiki. Gives more tools to emulate PMwiki's group functions. Now all I need is an auto page creation on new group (base namespace) and I can fully copy my pm with my doku :D

If the user is in more groups than this page manages it would skip the test to see if the user was in any other groups! Comment out this line:

778: if (count($currentgroups) <= count($this->grplst)) {

Included in source now, no need to do this manually anymore, thank you 63.73.199.69! — Harald 2014/04/14 12:32

Line 521 calls the function modifyUser() directly when modifying the user rights rather than calling triggerUserMod() correctly as is done when creating or deleting a user. Doing it this way doesn't trigger the AUTH_USER_CHANGE event so other plugins can't respond to the change. To fix change:

521:  if ($auth->modifyUser($name, $update)) {

521:  if ($this->_auth->triggerUserMod('modify',array($name, $update))) {

Seems to work ok in my tests.

included in source, great to see the code improve! — Harald 2014/04/23 15:35

Hi Many thanks !!!! It's a very wonderful plugin ! For my use, i made a little tweak with which it's possible to configure several “root” namespaces if needed.

• file /lib/plugins/groupmanager/syntax.php
• after

            // empty tag?
            if (is_null($data[0]) || count($data[0]) == 0) {
                // load from conf namespace
                // build page name
                $conf_page = "";

• you can add

//splitter la chaîne en fonction du caractère "," dans un tableau
//split string after ","
  $tmp_tab = explode(',', $conf_namespace);
//boucle 
//loop over array  
  foreach($tmp_tab as $tmp_namespace)
  {
    //nettoyage - cleaning
      $tmp_namespace=trim($tmp_namespace, " ");
      $tmp_namespace=trim($tmp_namespace, ":");
    //chercher si le namespace en cours de traitement correspônd à l'ID de la page en cours
    //search if the "temp namespace" match the ID of the page
      if (substr($ID, 0, strlen($tmp_namespace)) == $tmp_namespace) {
         $conf_namespace=$tmp_namespace;
         break; 
      }
  }                  
 

That's all Thanks again